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Abstract 

We present an algorithm for efficiently testing Linear Temporal Logic (LTL) formulae on finite ex- 
ecution traces. The standard models of LTL are infinite traces, reflecting the behavior of reactive and 
concurrent systems which conceptually may be continuously alive. In most past applications of LTL. 
theorem provers and model checkers have been used to formally prove that down-scaled models satisfy 
such LTL specifications. Our goal is instead to use LTL for up-scaled testing of real software applica- 
tions. Such tests correspond to analyzing the conformance of finite traces against LTL formulae. We 
first describe what it means for a finite trace to satisfy an LTL property. We then suggest an optimized 
algorithm based on transforming LTL formulae. The work is done using the Maude rewriting system, 
which turns out to provide a perfect notation and an efficient rewriting engine for performing these 
experiments. 


1 Introduction 

Linear Temporal Logic (LTL), introduced by Pnueli in 1977 [31], is a logic for specifying temporal properties 
about reactive and concurrent systems. The models of LTL are infinite execution traces, reflecting the 
behavior of such systems as ideally always being ready to respond to requests, operating systems being 
an example. LTL has since then typically been used for specifying concurrent and interactive down-scaled 
models of real systems, such that fully formal program proofs could subsequently be carried out, for example 
using theorem provers [23, IS] or model checkers [21, 20]. However, such formal proof techniques are usually 
not scalable to real sized systems without an extra effort to abstract the system manually to a model w'hich 
is then analyzed. Model checking of programs has received an increased attention from the formal methods 
community within the last couple of years . Several systems have emerged that can model check source code, 
such as Java, C and C++ directly (typically subsets of these languages) [22, 35, 9, 2, 25, 30]. However, these 
techniques will only work if abstraction is applied to the code [8, 25, 36]. Alternatives to state recording 
model checking have also been tried, such as VeriSoft and similar tools [13, 34], which perform stateless model 
checking of C++ programs, and ESC [10], which uses a combination of static analysis and theorem proving 
to analyze Modula3 programs and recently also Java programs. We believe these techniques will show useful 
for targeted verification. However, although these systems provide very high confidence in the results they 
provide, they scale less well. One also needs techniques that can be applied instantly and in a completely 
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2.1 Maude 


M.unlr [6, . L 5] is ;i frtvly distributed htgh-perfunn;ina* system in tin* OBJ [10] algebraic specification 

familv, supporting both rewriting logic [28] and membership equational logic [29]. Because of its efficient 
rewriting engine. able to execute up to 2 million rewriting steps per second on currently standard hardware 
configurations, and because of its metalanguage features based on reflection [7], Maude turns out to be an 
excellent tool to create executable environments for various logics, models of computation, theorem provers, 
and even programming languages. We were delighted to notice how easily we could implement and efficiently 
validate our algorithms for testing LTL formulae on finite event traces in Maude, admittedly a tedious task 
in C++ or Java, and hence decided to use Maude at least for the prototyping stage of our runtime check 
algorithms. 

We very briefly and informally remind some of Maude's features, referring the interested reader to the 
manuals [4, 5] for more details. We'll restrict our attention to only Maude's module system and order-sorted 
equational logic since we don't need more for this paper. Maude supports modularization in the CLEAR 
[1] and OBJ [16] style of parameterized programming, with highly generic and reusable modules. There are 
various kinds of modules, but w r e are using only functional modules which follow the pattern "f mod <name> 
is <body> endfm”. The body of a functional module consists of a collection of declarations, of which we are 
using importing, sorts, subsorts, operations, variables and equations, usually in this order. We'll describe all 
these "on the fly", as they appear in the paper. 

2.2 Propositional Calculus 

This subsection presents a decision procedure for propositional calculus due to Hsiang [26] which makes high 
use of associative/commutative axioms. It provides the usual truth constants (true and false) together 
with a potentially infinite set. of propositional variables, and also the usual connectives _/\_ (conjunction). 
_++_ (exclusive disjunction), _\/_ (disjunction), !_ (negation), _->_(implication), and (equivalence). 

The procedure reduces tautology formulae to the constant true and all the others to some canonical form 
modulo associativity and commutativity. 

The first algebraic specification code for this reduction procedure seems to have originally appeared in 
[15] in the language OBJ1. and then its OBJ3 code appeared in [16]. Below w*e give its obvious translation to 
Maude, noticing that Hsiang [26] showed that this rewriting system modulo associativity and commutativity 
is Church- Rosser and terminates. The Maude team w*as probably also inspired by this procedure, since 
the built in BOOL module is very similar, the main difference being that BOOL does not allow distinguishable 
identifiers as boolean formulae and that the connectives are actually spelled, i.e.. _/\_ is replaced by _and_. 
_++_ by _xor_, by _iraplies_, etc. 

fmod PROPOSITIONAL-CALCULUS is 
protecting QID . 
sort Formula . 
subsort Qid < Formula . 

*** Constructors *** 
ops true false : -> Formula . 

op : Formula Formula -> Formula [assoc comm prec 15] 

op _++_ : Formula Formula -> Formula [assoc comm prec 17] . 

vars X Y 2 : Formula . 

eq true /\ X * X . 

eq false /\ X 3 false . 

eq X /\ X * X . 

eq false ++ X 3 X . 

eq X ♦+ X 3 false . 

eq X A (Y ♦+ Z) * X A Y ++ X /\ Z . 

*** Derived operators *** 

op _\/- : Formula Formula -> Formula [assoc prec 19] 

op !_ : Formula -> Formula [prec 13] . 

op : Formula Formula -> Formula [prec 21] 

op : Formula Formula -> Formula [prec 23] . 
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3 Finite Trace Linear Temporal Logic 

As already explained, our goal is to develop a framework tor testing soltware systems using temporal logic. 
Tests are performed ori Unite execution tract's and we therefore need to formalize what it means for a 
finite trace to satisfy an LTL formula. First we present a semantics ot LTL on finite traces using standard 
mathematical notation. Then we present a specification in Maude of a finite trace semantics. Whereas the 
former semantics uses universal and existential quantification, the second Maude specification is defined using 
recursive definitions that have a straightforward operational rewriting interpretation and which therefore can 
be executed. 

3.1 Finite Trace Semantics 

In this subsection we present a semantics of LTL on finite traces. W’e will regard a trace as a finite sequence 
of events emitted from the program that we want to observe. Such events could for example indicate when 
variables are written to. For example, the event write(x.v) would mean that “x is assigned the value v \ 
Note that this view is slightly different from the traditional view where a trace is a sequence of program 
states, each state denoting the set of propositions that hold at that state. Our view' is consistent with our 
goal to define an LTL observer as a process that is detached from the program to be observed, receiving only 
observed events. W’e shall abstract away from the concrete contents of events and just define events as a set 
of distinguishable identifiers. The following Maude module formalizes this idea: 

fmod EVENT is 
protecting QID . 
sort Event . 
subsort Qid < Event 
endfm 

It introduces the sort Event and states that the sort Qid of distinguishable identifiers is a subsort of Event. 
A trace is now a finite list of events. This is modeled by the following Maude specification: 

fmod TRACE is 

extending EVENT . 
sort Trace . 
op end : -> Trace . 

op __ ; Event Trace -> Trace [prec 25] . 

endfm 

It introduces the sort Trace and the constructors end for the empty trace, and juxtaposition of an event 
u e” and a trace as in “e t ” t for creating a new trace. We shall outline the finite trace LTL semantics 
using standard mathematical notation rather than Maude notation. Assume tw’o partial functions defined for 
nonempty traces head : Trace Event and tail : Trace — > Trace for taking the head and tail respectively of 
a trace, and a total function length returning the length of a finite trace. That is, head(e t) = e, tail(e t) = £, 
and length(end) = 0 and length(e t) = 1 + length(t). Assume further for any trace t that t t for some natural 
number i denotes the suffix trace that starts at position i, with positions starting at 1. The satisfaction 
relation (= C Trace x Formula defines when a trace t satisfies a formula /, written t [= /, and is defined 
inductively over the structure of the formulae as follows, where P is any quoted identifier and X and Y are 
any formulae: 
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P 
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iff 
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false 
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’a 'b 'a 'b ’a ’ c ’a ’a ‘b ’ g ' f 'h 'c 'b ’a end . 
eq formula! = [] (*b -> <> *c) 

eq formula2 - <> (! formula!) 

eq forraula3 = [] ((('a /\ o’b) \/ ('b /\ o’a)) U ('a /\ o'c)) 
endfm 


where the three vertical dots in trace3 stand for 100 repetitions of the previous sequence of events* t and 
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The algorithm to test LTL formulae on traces presented above does nothing else but blindly follow the 
mathematical definition of satisfaction (so it is correct) and even runs reasonably fast for relatively small 
traces. For example, it takes less than 10.000 rewriting steps (a few milliseconds) to reduce any of the first 
4 goals involving only traces of 15 events. Unfortunately this algorithm doesn't seem to be tractable for 
large event traces, even if run on very fast and large memory machines. That’s because the number of 
atoms of the form T I = X in the boolean formula to be reduced keeps growing exponentially: besides that, 
the boolean reduction engine is itself intractable (it works modulo associativity and commutativity). As a 
practical example, it took Maude 3 million rewriting steps to reduce the fifth expression above. 53 million 
steps for the sixth, and it couldn’t finish the last one in 10 hours. 

Since the event traces generated by an executing program can easily be larger than 5,000 events, the 
trivial algorithm above can not be used in real practical situations. 


4 An Efficient Rewriting Algorithm 

In this section we shall present a more efficient rewTiting semantics. First we shall motivate the design choice. 
Then follows the algorithm, and finally we prove that the new* semantics is equivalent to the one given in 
the previous section. 

4.1 Motivation 

The operational Maude semantics of LTL that was presented in the previous section is not efficient due to 

the fact that the traces are carried around in several subexpressions. For example, the semantics of the until 

operator is given as follows: 

eq E T |= X U Y = E T I = Y or E T |= X and T |= X U Y . 

We can see that the trace T occurs in three subexpressions. A more efficient algorithm is presented below, 

which is based on the idea of consuming the events in the trace, one by one, and updating a data structure, 
say of type D , corresponding to the effect of the event on the value of the formula. Hence, we should define 
a function transform : Event x D — » D. Our decision to write an operational Maude semantics this way was 
motivated by an attempt to program such an algorithm in Java, where such a solution would be the most 
natural. As it turns out, it also yields a more efficient rewriting system. 

We have considered two approaches: an automata approach and a formula approach. In the automata 
approach one could translate the formula into an automaton, and then take the synchronized product of the 

4 The three vertical dots are not a Maude feature. 
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A propositional identifier is transformed to true it the event equals that. proposition, otherwise false. The 
rule for the temporal operator []X should he read as follows: the formula X must hold now ( X { E } ) and also 
in the future ([]X). The sub-expression X{E} represents the formula that must hold for the rest ot the trace* 
for X to hold now As an example, consider the* formula [] <>P where P is a propositional identifier. This 
formula applied to the distinct proposition Q yields the following rewrit ings: 

( □ <>P) {Q} => []<>P /\ (<>P){Q> 

= > []<>P /\ (<>P \/ P {Q } ) 

=> []<>P /\ (<>P \/ false) 

=> []<>P /\ <>P 

As we can see, the property <>P has been spawned off as a consequence of the Q event, in addition to the 
original formula that still has to hold due to the “[]” operator 

Note that these rules spell out the semantics of each temporal operator. An alternative solution would 
be to define some operators in terms of others, as is typically the case in the standard semantics for LTL. For 
example, we could introduce an equation of the form: <>X = true U X, and then eliminate the rewriting 
rule for <>X in the above module. Interestingly enough this turns out to be less efficient, a result that we 
had not quite expected since propositional logic rewriting seems to benefit from rewriting into normal forms 
as demonstrated with the module PROPOSITIONAL-CALCULUS described in Subsection 2.2. 

4.3 Revised Semantics 

Before we complete the definition of our fast algorithm to evaluate formulae on finite traces, we need to 
introduce a new operation, eval, which basically "evaluates'’ to either true or false a formula as it is , that 
is, without using any information about the trace. This operation is needed when all the events in the trace 
are consumed, and basically spells out what the semantics of a formula is on an empty trace. 

fmod EVAL is 

protecting LINEAR-TEMPORAL- LOGIC . 
op eval : Formula -> Bool . 
var P : Qid . vars X Y : Formula . 
eq eval(P) * false . 

eq eval (true) * true . 
eq eval(false) = false . 
eq eval (X /\ Y) = eval(X) and eval(Y) . 
eq eval(X ♦+ Y) = eval(X) xor eval(Y) 
eq eval([] X) = true . 
eq eval(<> X) * eval(X) . 
eq eval(X U Y) * eval(Y) 
eq eval(o X) * false . 
endfm 

The eval function can be seen as a morphism of logics, which maps all atomic propositions to false. The 
intuition here is that at the end of a trace, no propositions hold. The module in particular explains the 
semantics of the temporal operators on the empty trace. Now, the revised semantics of finite trace linear 
temporal logic can be implemented as follows: 

fmod FINITE-TRACE-SEMANTICS-REVISED is 
protecting CONSUME-EVENT . 
protecting TRACE . 
protecting EVAL . 

op « I - _ : Trace Formula -> Bool [prec 30] . 
var E : Event . var T : Trace . var X : Formula . 
eq end |- X * eval(X) . 
eq E T I- X - T I- X {E> . 
endfm 
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f mod PROOF-OF-LEMMAS is 

extending FIN TTE-TRACE- SEMANTICS . 
extending FINITE-TRACE-SEMANTICS-REVISED . 
op e : ’> Event op t : -> Trace . 
ops p q : -> Qid . ops y z : -> Formula . 
eq end 1 3 y = end I - y . 

eq end ! = z = end I - z . 

eqet 1 3 y = t I = y {e> . 

eqet I = z 3 t \- z (e } . 

endfm 

It is worth reminding the reader at this stage that the functional modules in Maude have initial semantics, 
so proofs by induction are valid. In particular, notice that an event can only be a specialized identifier since 
there are no other operations generating events. Before proceeding further, the reader should be aware of 
the operational semantics of the operation namely that the two argument terms are first reduced to 

their normal forms which are then compared syntactically (but modulo associativity and commutativity); it 
returns true if and only if the two normal forms are equal. Therefore, the answer true means that the two 
terms are indeed semantically equal, while false only means that they couldn't be proved equal; they can 
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The returned answer is indeed true; it took Maude 129 reductions to prove these lemmas. Notice the case 
analysis on the event e at the beginning of the second lemma’s proof. Therefore, one can safely add now* 
these lemmas as follows: 

fmod LEMMAS is 

protecting FINITE-TRACE-SEMANTICS . 
protecting FINITE-TRACE-SEMANTICS-REVISED . 
var E : Event . var T : Trace . var X : Formula . 
eq end I * X * end I - X . 
eqET I * X * T I = X {E} . 
endfm 

We can now proceed to the proof of the theorem, by induction on traces. More precisely, we show: 
'P(end), and 

P(T) implies P(E T), for all events E and traces T, 

where P(T) is the predicate w for all formulas X, T 1= X iff T |- X”. This induction schema can be easily 
formalized in Maude as follows: 
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